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Abstract 

Functional programming languages use garbage collection for heap memory management. Ideally, garbage collectors should 
reclaim all objects that are dead at the time of garbage collection. An object is dead at an execution instant if it is not used in 
future. Garbage collectors collect only those dead objects that are not reachable from any program variable. This is because 
they are not able to distinguish between reachable objects that are dead and reachable objects that are live. 
In this paper, we describe a static analysis to discover reachable dead objects in programs written in first-order, eager func- 
tional programming languages. The results of this technique can be used to make reachable dead objects unreachable, thereby 
allowing garbage collectors to reclaim more dead objects. 

Keywords: Compilers, Liveness, Garbage Collection, Memory Management, Data Flow Analysis, Context Free Grammars 



1 Introduction 

Garbage collection is an attractive alternative to manual memory management because it 
frees the programmer from the responsibility of keeping track of object lifetimes. This 
makes programs easier to implement, understand and maintain. Ideally, garbage collectors 
should reclaim all objects that are dead at the time of garbage collection. An object is 
dead at an execution instant if it is not used in future. Since garbage collectors are not able 
to distinguish between reachable objects that are live and reachable objects that are dead, 
they conservatively approximate the liveness of an object by its reachability from a set of 
locations called root set (stack locations and registers containing program variables) [14]. 
As a consequence, many dead objects are left uncollected. This has been confirmed by 
empirical studies for Haskell [19], Scheme [16] and Java [22,23,24]. 

Compile time analysis can help in distinguishing reachable objects that are live from 
reachable objects that are dead. This is done by detecting unused references to objects. 
If an object is dead at a program point, none of its references are used by the program 
beyond that program point. If every unused reference is nullified, then the dead objects 
may become unreachable and may be claimed by garbage collector. 
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(define (app listl Iist2) 
Jli 7t 2 :(null? JI3 : 1 istl) 
7t 4 :list2 

715 :(cons ii(,:(car %j : I istl) 

7ig :(app 719 :(cdr TCio rlistl) 
7in:list2)))) 
(let z < — (cons (cons 4 (cons 5 Nil)) 

(cons 6 Nil)) in 
(let y <— (cons 3 A///) /n 

%i2 :(let w <— 7113 :(app y z) /n 

7114 :(car (car (cdr w)))))) 

(a) Example program. 




(b) Memory graph at 7t 14 . 

Thick edges denote live links. 
Edges marked x can be nullified. 



Fig. 1 . Example Program and its Memory Graph. 

Example 1.1 Figure 1(a) shows an example program. The label 7t of an expression e de- 
notes the program point just before the evaluation of e. At a given program point, the heap 
memory can be viewed as a (possibly unconnected) directed acyclic graph called memory 
graph. The locations in the root set form the entry nodes for the memory graph. Fig- 
ure 1(b) shows the memory graph at 7114. Each cons cell is an intermediate node in the 
graph. Elements of basic data types and the 0-ary constructor Nil form leaf nodes of the 
graph. They are assumed to be boxed, i.e. stored in separate heap cells and are accessed 
through references. The edges in the graph are called links. 

If we consider the execution of the program starting from 71 14, the links in the memory 
graph that are traversed are shown by thick arrows. These links are live at 7114. Links that 
are not live can be nullified by the compiler by inserting suitable statements. If an object 
becomes unreachable due to nullification, it can be collected by the garbage collector. 

In the figure, the links that can be nullified are shown with a x . Note that a link need 
not be nullified if nullifying some other link makes it unreachable from the root set. If a 
node becomes unreachable from the root set as a consequence of nullifying the links, it will 
be collected during the next invocation of garbage collector. □ 

In this example, starting at 7114, there is only one execution path. In general, there could 
be multiple execution paths starting from a program point 7t. The liveness information at 71 
is a combination of liveness information along every execution path starting at 7t. 

In this paper, we describe a static analysis for programs written in first-order, eager 
functional programming languages. The analysis discovers live references at every program 
point, i.e. the references that may be used beyond the program point in any execution of 
the program. We use context free grammars as a bounded representation for the set of live 
references. The result of the analysis can be used by the compiler to decide whether a given 
reference can be nullified at a given program point. Our analysis is context-sensitive yet 
modular in that a function is analyzed only once. 

The rest of the paper is organized as follows: Section 2 describes the language used to 
explain our analysis along with the basic concepts and notations. The analysis in Section 3 
captures the liveness information of a program as a set of equations. The method to solve 
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p 
d 



d\...d n e\ 
(define (fv\ . 



v n ) ei) 



— program 



function definition 



e 



— expression 



K — constant 

v — variable 

Nil — primitive constructor 

(conse\ e 2 ) — primitive constructor 

(care\) — primitive selector 

(cdre\) — primitive selector 

(pair? e\) — primitive tester 

(null?e\) — primitive tester 

(+ e\ ej) — generic primitive 

(ife[ ^2 £3) — conditional 
(letv\ <— e 2 inei) — let binding 

(/ e\ . .. e n ) — function application 



Fig. 2. The syntax of our language 



these equations is given in Section 4. Section 5 describes how the result of the analysis can 
be used to nullify unused references. Finally, we compare our approach with related work 
in Section 6 and conclude in Section 7. 

2 Language, Concepts and Notations 

The syntax of our language is described in Figure 2. The language has call-by-value seman- 
tics. The argument expressions are evaluated from left to right. We assume that variables 
in the program are renamed so that the same name is not defined in two different scopes. 

For notational convenience, the left link (corresponding to the car) of a cons cell is 
denoted by and the right link (corresponding to the cdr) is denoted by 1. We use e.O to 
denote the link corresponding to (care) for an expression e (assuming e evaluates to a list) 
and e.l to denote the link corresponding to (cdre). A composition of several cars and cdrs 
is represented by a string a G {0,1}*. If an expression e evaluates to a cons cell then e.E 
corresponds to the reference to the cons cell. 

For an expression e, let [e] denote the location in the root set holding the value of e. 
Given a memory graph, the string e.a describes a path in the memory graph that starts 
at [e]. We call the string e.a an access expression, the string a an access pattern, and 
the path traced in the memory graph an access path. In Figure 1, the access expression 
w.100 represents the access path from w to the node containing the value 4. Most often, 
the memory graph being referred to is clear from the context, and therefore we shall use 
access expressions to refer to access paths. When we use an access path to refer to a link in 
the memory graph, it denotes the last link in the access path. Thus, w.100 denotes the link 
incident on the node containing the value 4. If o denotes a set of access patterns, then e.a 
is the set of access paths rooted at [e] and corresponding to a. i.e. 

e.o = {e.a \ a e a} 

A link in a memory graph is live at a program point 71 if it is used in some path from 71 
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to the program exit. An access path is defined to be live if its last link is live. In Example 1 , 
the set of live access paths at 7144 is {w.£, w.l, w.10, w.100,z.0,z.00}. Note that the access 
paths z.O and z.00 are live at 7114 due to sharing. We do not discover the liveness of such 
access paths directly. Instead, we assume that an optimizer using our analysis will use alias 
analysis to discover liveness due to sharing. 

The end result of our analysis is the annotation of every expression in the program 
with a set of access paths rooted at program variables. We call this liveness environment, 
denoted L . This information can be used to insert nullifying statements before expressions. 

The symbols and 1 extend the access patterns of a structure to describe the access 
patterns of a larger structure. In some situations, we need to create access patterns of a 
substructure from the access patterns of a larger structure. For this purpose, we extend our 
alphabet of access patterns to include symbols and 1. The following example motivates 
the need for these symbols. 

Example 2.1 Consider the expression at program point 71 1 in 

7li :(/et w <— 7t 2 :(cons x y) in 7I3 :• • •) 

Assuming L %i = {w.a}, we would like to find out which reference of the list x and y are 
live at 71 1. Let x.a' be live at K\. Then, the two possible cases are: 

• If a = 1[3 or a = £, no link in the structure rooted at x is used. We use _L to denote the 
access pattern describing such a situation. Thus, a' = _L. 

• If a = OP then the link represented by w.a that is x rooted and live at Tti can be repre- 
sented by x.p. Thus, a' = p\ 

This relation between a and a' is expressed by a' = Ooc. 1 can be interpreted similarly. □ 

With the inclusion of 0, 1 and _L in the alphabet for access patterns, an access pattern 
does not directly describe a path in the memory graph. Hence we define a Canonical Access 
Pattern as a string restricted to the alphabet {0,1}. As a special case, _L is also considered 
as a canonical access pattern. 

We define rules to reduce access patterns to their canonical forms. For access patterns 
OCi and a 2 : 



(3) ai±a 2 ^_L 

a-^a 1 denotes the reduction of a to a' in k steps, and denotes the reflexive and transitive 
closure of — >. The concatenation (•) of a set of access patterns Gi with G 2 is defined as a 
set containing concatenation of each element in ai with each element in G 2 , i.e. 

ai -a 2 = {aia 2 1 oci eci,a 2 ea 2 } 
3 Computing Liveness Environments 

Let a be the set of access patterns specifying the liveness of the result of evaluating e. Let 
L be the liveness environment after the evaluation of e. Then the liveness environment 
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before the computation of e is discovered by propagating a backwards through the body of 
e. This is achieved by defining an environment transformer for e, denoted X T . 

Since e may contain applications of primitive operations and user defined functions, 
we also need transfer functions that propagate a from the result of the application to the 
arguments. These functions are denoted by X T and X J . While X T is given directly based 
on the semantics of the primitive, X J is inferred from the body of a function. 



3. 1 Computing X T 

For an expression e at program point ji, XT, (e,a,L) computes liveness environment at ji 
where a is the set of access patterns specifying the liveness of the result of evaluating e 
and L is the liveness environment after the evaluation of e. Additionally, as a side effect, 
the program point 71 is annotated with the value computed. However, we do not show this 
explicitly to avoid clutter. The computation of X T(e,G,L) is as follows. 

(4) xt(k,g,l)=l 

(5) XT(v,G,L) = LUv.G 

(6) XT((Pe\ e 2 ),G,L) = let l' <— XT(e 2 ,XTp(G),L) in 

X<E(ei,X<p£(<o),L') 
where P is one of cons, + 

(7) XT{{Pei),G,L) = XT(e l ,XP p 1 (G),L) 

where P is one of car, cdr, null?, pair? 

(8) X<E((ife\ e 2 e 3 ),o,L) = let l' <— XE(e 3 ,a,x) in 

letL" <- X l E(e 2 ,a,L) in 
X£(ei,{e},x'Ul") 

(9) XT,((letvi <—ei ine 2 ),G,L) = let <— X-E(e 2 ,G,L) in 

XE(ei,a',x'- vi.a') 
where a' = {a | v\ .a € l'} 

(10) X-E((fei...e n ),G,L) = letLi <- XT, (e n ,X!F?(o),L) in 

letL n - X ^XT{e 2 ,X7f{G),L n - 2 ) in 

XT{e x ,X7}{G),L n - X ) 

We explain the definition of XT for the if expression. Since the value of the conditional 
expression e\ is boolean and this value is used, the liveness access pattern with respect to 
which e\ is computed is {e}. Further, since it is not possible to statically determine whether 
e 2 or <?3 will be executed, the liveness environment with respect to which e\ is computed is 
the union of the liveness environments arising out of e 2 and e^. 



3. 2 Computing X (P and X T 

If a is the set of access patterns specifying the liveness of the result of evaluating (P e\ . . . e n ), 
where Pisa primitive, then X Tp(a) gives the set of access patterns specifying the liveness 
of e,. We describe the transfer functions for the primitives in our language: car, cdr, cons, 
null?, pair? and +. The 0-ary constructor Nil does not accept any argument and is ignored. 
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Assume that the live access pattern for the result of the expression (car e) is oc. Then, 
the link that is denoted by the path labeled a starting from location [(care)] can also be 
denoted by a path Ooc starting from location [e\. We can extend the same reasoning for set 
of access patterns (a) of result, i.e. every pattern in the set is prefixed by to give live 
access pattern of e. Also, since the cell corresponding to e is used to find the value of car, 
we need to add £ to the live access patterns of e. Reasoning about (cdre) similarly, we have 

(11) x*2 ar (a) = {E}U{0}-a, x? c 1 c/f (a) = {e}u{l}-0 

As seen in Example 2.1, an access pattern of a for result of cons translates to an access 
pattern of 0oc for its first argument, and la for its second argument. Since cons does not 
read its arguments, the access patterns of the arguments do not contain £. 

(12) x^ ons (a) = {0}-a, x^ ons (a) = {l}-o 

Since the remaining primitives read only the value of the arguments, the set of live access 
patterns of the arguments is {s}. 

( 13 ) XP null?^ = Xrp pa/V?( a ) = { e >> ** + (°) = { e }> X<P*(c) = {e} 

We now consider the transfer function for a user defined function /. If a is the set of 
access patterns specifying the liveness of the result of evaluating (/ e\ . . . e n ), then X 1 j(o) 
gives the set of access patterns specifying the liveness of e,. Let / be defined as: 

(define (fv\ ... v n ) n : e) 

Assume that a is the live access pattern for the result of /. Then, a is also the live access 
pattern for e. X£(e,a,0) computes live access patterns for v, (1 < i < n) at ji. Thus, the 
transfer function for the i th argument of / is given by: 

(14) x7 l f {o) = {a\ Vi.aeK(e,0,fl)} l<j<n 
The following example illustrates our analysis. 

Example 3.1 Consider the program in Figure 1. To compute the transfer functions for app, 
we compute the environment transformer JC£(e,o,0) in terms of a variable a. Here e is 
the body of app. The value of the liveness environment at each point in the body of app is 
shown in Appendix A. From the liveness information at jui we get: 

X r£pp(a) = {£} U {00} • a U {1} • x ^({1} ■ °) 
x^i pp (o)=aUX!Fi pp ({l}-a) 

Let e pgm represent the entire program being analyzed and <T pgm be the set of access 
patterns describing the liveness of the result. Then, the liveness environment at various 
points in the e pgm can be computed as X E (e pgm ,Gpg m ,0). The liveness environments at 
7ti4 and Tin are as follows: 

L Kl4 = { w.({e, 1, 10} U {100} • a pgm ) } 

f y.x^ a 1 pp ({8,l,10}u{100}-a pgm ), ) 
7112 \ z.XiF a f pp ({e,l,10}u{100}-a pgm ) j 

□ 

We assume that the entire result of the program is needed, i.e., <7 pgm is {0, 1}*. 
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4 Solving the Equations for x <F 

In general, the equations defining the transfer functions X 1 will be recursive. To solve 
such equations, we start by guessing that the solution will be of the form: 

(15) Atfj(o) = /}U®}-o, 

where ij- and are sets of strings over the alphabet {0, 1,0, 1}. The intuition behind this 
form of solution is as follows: The function / can use its argument locally and/or copy a 
part of it to the return value being computed. Ji- is the live access pattern of i th argument 
due to local use in /. £>y is a sort of selector that selects the liveness pattern corresponding 
to the i th argument of / from a, the liveness pattern of the return value. 

If we substitute the guessed form of X fl in the equations describing it and equate the 
terms containing o and the terms without a, we get the equations for ij and This is 
illustrated in the following example. 

Example 4.1 Consider the equation for jFapp(<J) from Example 3.1: 

x fFapp(°) = M U {00} -au{l}-x ^({1} • a) 
Decomposing both sides of the equation, and rearranging the RHS gives: 
'ipp u ®ipp • = {e} u {00} • cu {1} • (/i pp u ©i p p • {1} • a) 
= {s} u {1} • / a ! pp u {00} • a u {1} • © app • {1} • a 

Separating the parts that are a dependent and the parts that are o independent, and equating 
them separately, we get: 

'ipp^iuUWipp 

©app ' o = {00} • a U {1} • ©ip p • {1}g 
= ({00}u{l}-^p p -{l})-a 
As the equations hold for any general a, we can simplify them to: 

'app = {e}U{l}-/ a 1 pp and © app = {00} U {1} • ©^ pp • {1} 
Similarly, from the equation describing X !F 3 pp(o), we get: 

'a 2 pp = -ra 2 pp and ©| pp = {e} U ©| pp . {1} 
The liveness environment at 7li2 and Ku in terms / a pp and © a pp are: 

Ai 14 = {w.{100}-G pgm } 

. fy-Uapp u ©app-({M>10}U{100}-a pgm )U 
7112 U('a 2 pp U © a 2 p p -({s,l,10}U{100}-G pgm )) J 
Solving for / a pp and f a pp gives us the desired liveness environments at these program 
points. □ 

4.1 Representing Liveness by Context Free Grammars 

The values of / and 2) variables of a transfer function are sets of strings over the alphabet 
{0, 1,0, 1}. We use context free grammars (CFG) to describe these sets. The set of terminal 
symbols of the CFG is {0,1,0,1}. Non-terminals and associated rules are constructed as 
illustrated in Examples 4.2 and 4.3. 
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Example 4.2 Consider the following constraint from Example 4. 1 : 

'ippH^uW-^pp 

We add non-terminal (/app) an d the productions with right hand sides directly derived 
from the constraints: 

C^app) — ¥ e I l(^app) 
The productions generated from other constraints of Example 4.1 are: 

(®app)-00|l(© ap p)l 

( J app) ~* (-^app) 

(®ipp)^e| <©app)I 
These productions describe the transfer functions of a pp. □ 

The liveness environment at each program point can be represented as a CFG with a 
start symbol for every variable. To do so, the analysis starts with (5 pgm ), the non-terminal 
describing the liveness pattern of the result of the program, G pgm . The productions for 
(Spgm) are: 

(Spgm) — ►£ | 0(.Spg m } | l(5 , pgm ) 

Example 4.3 Let S% denote the non-terminal generating liveness access patterns associated 
with a variable v at program point n. For the program of Figure 1 : 

Pgm/ 

(^ 12 ) - </ a 2 pp) | (2>!pp) I (2>ipp>l I (®a 2 pp)10 | (2>a 2 pp)100(5 pgm ) 

($ 12 > -> (lipp) I <©app> I <2>app)l I (^pp)lO | (©^pp)100(5 pgm ) □ 

The access patterns in the access paths used for nullification are in canonical form 
but the access patterns described by the CFGs resulting out of our analysis are not. It is 
not obvious how to check the membership of a canonical access pattern in such CFGs. 
To solve this problem, we need equivalent CFGs such that if a belongs to an original 
CFG and a — > p\ where [3 is in canonical form, then p" belongs to the corresponding new 
CFG. Directly converting the reduction rules (Equations (1, 2, 3)) into productions and 
adding it to the grammar results in unrestricted grammar [11]. To simplify the problem, 
we approximate original CFGs by non-deterministic finite automata (NFAs) and eliminate 
and 1 from the NFAs. 



4.2 Approximating CFGs using NFAs 

The conversion of a CFG G to an approximate NFA N should be safe in that the language 
accepted by N should be a superset of the language accepted by G. We use the algorithm 
described by Mohri and Nederhof [18]. The algorithm transforms a CFG to a restricted 
form called strongly regular CFG which can be converted easily to a finite automaton. 

Example 4.4 We show the approximate NFAs for each of the non-terminals in Exam- 
ple 4.2 and Example 4.3. 

1 

t tft 
start /f=\ 

pgm/- \ J app/' 




(Spgm ) ; ^UL ('app) 
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Note that there is no automaton for (/|pn). This is because the least solution of the equa- 
tion (iipp) — * (^app) i s ®- Also, the language accepted by the automaton for ©app * s 
approximate as it does not ensure that there is an equal number of 1 and 1 in the strings 
generated by rules for (2>app)- D 

4.3 Eliminating and 1 from NFA 

We now describe how to convert an NFA with transitions on symbols and 1 to an equiva- 
lent NFA without any transitions on these symbols. 

Input: An NFA N with underlying alphabet {0, 1,0, 1} accepting a set of access patterns 
Output: An NFA N with underlying alphabet {0, 1} accepting the equivalent set of canon- 
ical access patterns 
Steps: 

i<-0 

No <— Equivalent NFA of N without £-moves [11] 
do { 

foreach state q in N,- such that q has an incoming edge from q' 
with label and outgoing edge to q" with label { 
/* bypass 00 using e */ 

add an edge in NJ +1 from q' to q" with label £. 

} 

foreach state q in N,- such that q has an incoming edge from q' 
with label 1 and outgoing edge to q" with label 1 { 
/* bypass 11 using e ★/ 

add an edge in N- +1 from q' to q" with label e. 

Nj+i <— Equivalent NFA of N- +1 without e-moves 

i <- i + 1 
} while (N/^Ni-0 
N^N ; - 

delete all edges with label or 1 in N. 

The algorithm repeatedly introduces £ edges to bypass a pair of consecutive edges labeled 
00 or 11. The process is continued till a fixed point is reached. When the fixed point is 
reached, the resulting NFA contains the canonical access patterns corresponding to all the 
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access patterns in the original NFA. The access patterns not in canonical form are deleted 
by removing edges labeled and 1. Note that by our reduction rules if a is accepted by 
N and a — > _L, then ± should be accepted by N, However, N returned by our algorithm 
does not accept _L. This is not a problem because the access patterns which are tested for 
membership against N do not include _L as well. 

Example 4.5 We show the elimination of and 1 for the automata for (5^ 12 ) and (SJ ). 
The automaton for (5^ ) remains unchanged as it does not contain transitions on and 1. 
The automata at the termination of the loop in the algorithm are: 





Eliminating the edges labeled and 1, and removing the dead states gives: 

The language accepted by these automata represent the live access paths corresponding to 
y and z at JI12. □ 

We now prove the termination and correctness of our algorithm. 
Termination 

Termination of the algorithm follows from the fact that every iteration of do-while loop 
adds new edges to the NFA, while old edges are not deleted. Since no new states are added 
to NFA, only a fixed number of edges can be added before we reach a fix point. 



Correctness 

The sequence of obtaining N from N can be viewed as follows, with N m denoting the NFA 
at the termination of while loop: 



— deletion ^ T addition . deletion ^ T addition 

N - — r^No ^— — 77* Nj — - 2 Ni 



addition < deletion 

K - — r*N/- 



of e-edges of e-edges of E-edges of e-edges of E-edges 1 of £-edges 



deletion 
of E-edges 



N„ 



N„ 



deletion of. 



■N 



0, 1 edges 

Then, the languages accepted by these NFAs have the following relation: 

L(N) = L(N ) C L(Ni) = L(N X ) C ■ • • C L(N<) = L(N«) C ■ • • = L(N m ) 

L(N) C L(N m ) 

We first prove that the addition of 8-edges in the while loop does not add any new 
information, i.e. any access pattern accepted by the NFA after the addition of e-edges is a 
reduced version of some access pattern existing in the NFA before the addition of £-edges. 
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Lemma 4.6 for i > 0, if a G L(N,-) then there exists a' G L(N;_i) such that a' A a. 

Proof. As L(N,-) = £(N0, we have a G £(N-)- Only difference between N- and N,-_i is that 
N- contains some extra £-edges. Thus, any 8-edge free path in NJ is also in N,-_i. Consider 
a path p in Nj that accepts a. Assume the number of £ edges in p is k. The proof is by 
induction on k. 

(BASE) k = 0, i.e. p does not contains any 8-edge: As the path p is e-edge free, it must be 
present in N;_i. Thus, N,-_i also accepts a. a —> a. 

(HYPOTHESIS) For any a G L(N,-) with accepting path p having less than k £-edges there 
exists a' G L(N,_i) such that a' a. 

(INDUCTION) p contains k £-edges e\,... Assume connects states q' and a" in N-. 
By construction, there exists a state g in Nj such that there is an edge e\ from g' to q with 
label 0(1) and an edge e'[ from q to o" with label 0(1) in N-. Replace e\ by e\e'[ in to get a 

new path p" in N-. Let a" be the access pattern accepted by p" . Clearly, a" a. Since p" 
has k — 1 £-edges, a" is accepted by NJ along a path (p") that has less than k £-edges. By 

induction hypothesis, we have a' G L(N ; -_i) such that a' ^> a". This along with a" — > a 
gives a' — > a. □ 

Corollary 4.7 /or eac/i a G L(N m ), f/iere exists a' G L(N) ^mc/j that a' ^> a. 

Proof. The proof is by induction on m, and using Lemma 4.6. □ 

The following lemma shows that the the language accepted by N m is closed with respect 
to reduction of access patterns. 

Lemma 4.8 For a G L(N m ), if a ^> a' and a' ^ _L, then a' G L(N m ). 

Proof. Assume a —>■ a'. The Proof is by induction on k, number of steps in reduction. 
(BASE) case k = is trivial as a — > a. 

(HYPOTHESIS) Assume that for a G L(N m ), if a ^ a', then a' G L(N m ). 

(INDUCTION) a G L(N m ), a ^> a'. There exists a" such that: a a" a'. By 
induction hypothesis, we have a" G L(N,„). 

For a" ^> a' to hold we must have a" = OC1OO0C2 and a' = OC1OC2, or a" = OC1II0C2 and 
a' = OC1OC2. Consider the case when a" = (X1OO0C2. Any path in N m accepting a" must have 
the following structure (The states shown separately may not necessarily be different): 

As N m is the fixed point NFA for the iteration process described in the algorithm, adding 
an £-edge between states q' and q" will not change the language accepted by N m . But, the 
access pattern accepted after adding an £-edge is OC1OC2 = oc'. Thus, a' G L(N m ). The case 
when a" = OC1II0C2 is identical. □ 

Corollary 4.9 For a G L(N), ifa—>a! and a' ^ _L, then a' G L(N m ). 

Proof. L(N) C L(N m ) a G L(N m ). The proof follows from Lemma 4.8. □ 

The following theorem asserts the equivalence of N and N with respect to the equiva- 
lence of access patterns, i.e. every access pattern in N has an equivalent canonical access 
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pattern in N, and for every canonical access pattern in N, there exists an equivalent access 
pattern in N. 

Theorem 4.10 Let N be an NFA with underlying alphabet {0, 1,0, 1}. Let NFA N be the 

NFA with underlying alphabet {0, 1} returned by the algorithm. Then, 

(i) if OL E £(N), (3 is a canonical access pattern such that OC A p and P ^ _L, then [3 E L(N). 

(ii) i/p G L(N) then there exists an access pattern OC E L(N) such that a (3. 

Proof. 

(i) From Corollary 4.9: a E L(N),a A p and p ^ _L (3 E L(N m ). As p is in canonical 
form, the path accepting p in N m consists of edges labeled and 1 only. The same 
path exists in N. Thus N also accepts p P E L(N). 

(ii) L(N) C L(N m ) =4» P E L(N,„). Using Corollary 4.7, there exists a E L(N) such that 
a A p. 

□ 

5 An Application of Liveness Analysis 

The result of liveness analysis can be used to decide whether a given access path v.oc can be 
nullified at a given program point 7C. Let the link corresponding to v.oc in the memory graph 
be /. A naive approach is to nullify v.oc if it does not belongs to the liveness environment 
at 71. However, the approach is not safe because of two reasons: (a) The link / may be 
used beyond 71 through an alias, and may therefore be live, (b) a link I' in the access path 
from the root variable v to I may have been created along one execution path but not along 
another. Since the nullification of v.oc requires the link I' to be dereferenced, a run time 
exception may occur. 

To solve the first problem, we need an alias analysis phase to detect sharing of links 
among access paths. A link in the memory graph can be nullified at 7t if none of the access 
paths sharing it are live at 7C . To solve the second problem, we need an availability analysis 
phase. It detects whether all links in the access path have been created along all execution 
paths reaching 7C. The results of these analysis are used to filter out those access paths 
whose nullification may be unsafe. We do not address the descriptions of these analyses in 
this paper. 

6 Related Work 

In this paper, we have described a static analysis for inferring dead references in first order 
functional programs. We employ a context free grammar based abstraction for the heap. 
This is in the spirit of the work by Jones and Muchnick [13] for functional programs. The 
existing literature related to improving memory efficiency of programs can be categorized 
as follows: 

Compile time reuse. The method by Barth [2] detects memory cells with zero refer- 
ence count and reallocates them for further use in the program. Jones and Le Metayer [15] 
describe a sharing analysis based garbage collection for reusing of cells. Their analysis 
incorporates liveness information: A cell is collected even when it is shared provided ex- 
pressions sharing it do not need it for their evaluation. 
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Explicit reclamation. Shaham et. al. [25] use an automaton called heap safety automa- 
ton to model safety of inserting a free statement at a given program point. The analysis is 
based on shape analysis [20,21] and is very precise. The disadvantage of the analysis is 
that it is very inefficient and takes large time even for toy programs. Free-Me [7] combines 
a lightweight pointer analysis with liveness information that detects when short-lived ob- 
jects die and insert statements to free such objects. The analysis is simpler and cheaper as 
the scope is limited. The analysis described by Inoue et. al. [12] detects the scope (func- 
tion) out of which a cell becomes unreachable, and claims the cell using an explicit reclaim 
procedure whenever the execution goes out of that scope. Like our method, the result of 
their analysis is also represented using CFGs. The main difference between their work and 
ours is that we detect and nullify dead links at any point of the program, while they detect 
and collect objects that are unreachable at function boundaries. Cherem and Rugina [5] 
use a shape analysis framework [8] to analyze a single heap cell at a time for deallocation. 
However, multiple iterations of the analysis and the optimization steps are required, since 
freeing a cell might result in opportunities for more deallocations. 

Making dead objects unreachable. The most popular approach to make dead objects 
unreachable is to identify live variables in the program to reduce the root set to only the 
live reference variables [1]. The major drawback of this approach is that all heap objects 
reachable from the live root variables are considered live, even if some of them may not be 
used by the program. Escape analysis [3,4,6] based approaches discover objects escaping 
a procedure (an escaping object being an object whose lifetimes outlives the procedure that 
created it). All non-escaping objects are allocated on stack, thus becoming unreachable 
whenever the creating procedure exits. In Region based garbage collection [9], a static 
analysis called region inference [26] is used to identify regions that are storage for objects. 
Normal memory blocks can be allocated at any point in time; they are always allocated 
in a particular region and are deallocated at the end of that region's lifetime. Approaches 
based on escape analysis and region inference detect garbage only at the boundaries of 
certain predefined areas of the program. In our previous work [17], we have used bounded 
abstractions of access paths called access graphs to describe the liveness of memory links 
in imperative programs and have used this information to nullify dead links. 

A related work due to Heine and Lam [10] attempts to find potential memory leaks 
in C/C++ programs by detecting the earliest point in a program when an object becomes 
unreachable. 

7 Conclusions 

In this paper we presented a technique to compute liveness of heap data in functional pro- 
grams. This information could be used to nullify links in heap memory to improve garbage 
collection. We have abstracted the liveness information in the form of a CFG, which is then 
converted to NFAs. This conversion implies some imprecision. We present a novel way to 
simplify the NFAs so they directly describe paths in the heap. Unlike the method described 
by Inoue et. al. [12], our simplification does not cause any imprecision. 

In future, we intend to take this method to its logical conclusion by addressing the issue 
of nullification. This would require us to perform alias analysis which we feel can be done 
in a similar fashion. We also feel that with minor modification our method can be used for 
dead code elimination and intend to extend our analysis to higher order languages. 
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